Cross-chain interactions using a domain name scheme in blockchain systems

ABSTRACT

Implementations of the present disclosure include identifying, by a relay that is communicatively linked with a first blockchain instance and a second blockchain instance in a unified blockchain network, a blockchain domain name of a first blockchain instance; identifying a blockchain domain name of the second blockchain instance; receiving, from a node of the first blockchain instance, an access request for accessing the second blockchain instance, wherein the access request including the blockchain domain name of the second blockchain instance; identifying a chain identifier of the second blockchain instance based on the blockchain domain name of the second blockchain instance, wherein the chain identifier of the second blockchain instance indicates a blockchain network configuration of the second blockchain instance; and providing access to the second blockchain instance for the first blockchain instance based on the blockchain network configuration indicated by the chain identifier of the second blockchain instance.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/879,117, filed on May 20, 2020, which is a continuation of U.S.patent application Ser. No. 16/390,390, filed on Apr. 22, 2019, now U.S.Pat. No. 10,666,445, issued on May 26, 2020, which is a continuation ofPCT Application No. PCT/CN2018/115926, filed on Nov. 16, 2018. Eachapplication is hereby incorporated by reference in its entirety.

BACKGROUND

Distributed ledger systems (DLSs), which can also be referred to asconsensus networks, and/or blockchain networks, enable participatingentities to securely, and immutably store data. DLSs are commonlyreferred to as blockchain networks without referencing any particularuser case (e.g., crypto-currencies). Example types of blockchainnetworks can include public blockchain networks, private blockchainnetworks, and consortium blockchain networks. A public blockchainnetwork is open for all entities to use the DLS, and participate in theconsensus process. A private blockchain network is provided forparticular entity, which centrally controls read and write permissions.A consortium blockchain network is provided for a select group ofentities, which control the consensus process, and includes an accesscontrol layer.

Blockchains are used in crypto-currency networks, which enableparticipants to conduct transactions to buy/sell goods, and/or servicesusing a crypto-currency. A common crypto-currency includes Bitcoin. Incrypto-currency networks, record-keeping models are used to recordtransactions between users. Example record-keeping models include anunspent transaction output (UTXO) model, and account model (alsoreferred to as account-based model or account/balance model).

SUMMARY

Implementations of the present disclosure include computer-implementedmethods for a domain name scheme for blockchain systems. Moreparticularly, implementations of the present disclosure are directed tocross-chain interactions using a unified domain name scheme inblockchain systems.

In some implementations, actions include identifying, by a relay that iscommunicatively linked with a first blockchain instance and a secondblockchain instance in a unified blockchain network, a blockchain domainname of a first blockchain instance, wherein the blockchain domain nameof the second blockchain instance is a unique identifier of the secondblockchain instance and uniquely corresponds to a chain identifier ofthe second blockchain instance in the unified blockchain network;identifying a blockchain domain name of the second blockchain instance,wherein the blockchain domain name of the first blockchain instance is aunique identifier of the first blockchain instance and uniquelycorresponds to a chain identifier of the first blockchain instance inthe unified blockchain network; receiving, from a node of the firstblockchain instance, an access request for accessing the secondblockchain instance, wherein the access request including the blockchaindomain name of the second blockchain instance; identifying the chainidentifier of the second blockchain instance based on the blockchaindomain name of the second blockchain instance, wherein the chainidentifier of the second blockchain instance indicates a blockchainnetwork configuration of the second blockchain instance; and providingaccess to the second blockchain instance for the first blockchaininstance based on the blockchain network configuration indicated by thechain identifier of the second blockchain instance.

Other implementations include corresponding systems, apparatus, andcomputer programs, configured to perform the actions of the methodsencoded on computer storage devices.

These and other implementations may each optionally include one or moreof the following features:

A first feature, combinable with any of the following features, whereinidentifying a blockchain domain name of the first blockchain instanceincludes using the blockchain domain name of the first blockchaininstance as a local identifier of the first blockchain instance; and

wherein identifying a blockchain domain name of the second blockchaininstance includes using the blockchain domain name of the secondblockchain instance as a local identifier of the second blockchaininstance.

A second feature, combinable with any of the following features, whereinidentifying the chain identifier of the second blockchain instance basedon the blockchain domain name of the second blockchain instance includesidentifying the chain identifier of the second blockchain instanceaccording to look-up information locally stored at the relay based onthe blockchain domain name.

A third feature, combinable with any of the following features, whereinidentifying the chain identifier of the second blockchain instance basedon the blockchain domain name of the second blockchain instance includesidentifying the chain identifier of the second blockchain instance basedon the blockchain domain name of the second blockchain instance from aremote unified blockchain domain name server.

A fourth feature, combinable with any of the following features, whereinproviding, by the relay, access to the second blockchain instance forthe first blockchain instance based on the blockchain networkconfiguration indicated by the chain identifier of the second blockchaininstance includes providing, by the relay, access to the secondblockchain instance for the first blockchain instance via a secondrelay; wherein the blockchain network configuration indicated by thechain identifier of the second blockchain instance is identified by thesecond relay based on the same chain identifier of the second blockchaininstance; and wherein the second blockchain instance is accessed by thesecond relay based on the blockchain network configuration indicated bythe chain identifier of the second blockchain instance.

A fifth feature, combinable with any of the following features, whereinthe blockchain network configuration indicated by the chain identifierof the second blockchain instance is identified by the second relayaccording to look-up information locally stored at the second relaybased on the same chain identifier of the second blockchain instance.

A sixth feature, combinable with any of the following features, whereinthe blockchain network configuration indicated by the chain identifierof the second blockchain instance is identified by the second relaybased on the blockchain domain name of the second blockchain instancefrom a remote unified blockchain domain name server.

A seventh feature, combinable with any of the following features,wherein the blockchain domain name of the first blockchain instanceincludes a first human-readable label; and the blockchain domain name ofthe second blockchain instance includes a second human-readable label.

The present disclosure also provides one or more non-transitorycomputer-readable storage media coupled to one or more processors andhaving instructions stored thereon which, when executed by the one ormore processors, cause the one or more processors to perform operationsin accordance with implementations of the methods provided herein.

The present disclosure further provides a system for implementing themethods provided herein. The system includes one or more processors, anda computer-readable storage medium coupled to the one or more processorshaving instructions stored thereon which, when executed by the one ormore processors, cause the one or more processors to perform operationsin accordance with implementations of the methods provided herein.

It is appreciated that methods in accordance with the present disclosuremay include any combination of the aspects and features describedherein. That is, methods in accordance with the present disclosure arenot limited to the combinations of aspects and features specificallydescribed herein, but also include any combination of the aspects andfeatures provided.

The details of one or more implementations of the present disclosure areset forth in the accompanying drawings and the description below. Otherfeatures and advantages of the present disclosure will be apparent fromthe description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 depicts an example environment that can be used to executeimplementations of the present disclosure.

FIG. 2 depicts an example conceptual architecture in accordance withimplementations of the present disclosure.

FIG. 3 depicts an example unified blockchain domain name (UBCDN) of ablockchain instance, in accordance with implementations of the presentdisclosure.

FIG. 4 depicts an example UBCDN management scheme in a unifiedblockchain network, in accordance with implementations of the presentdisclosure.

FIG. 5 depicts an example process for using a blockchain domain name ofa blockchain instance for cross-chain interactions in a unifiedblockchain network, in accordance with implementations of the presentdisclosure.

FIG. 6 depicts an example process for authenticating a UBCDN of ablockchain instance, in accordance with implementations of the presentdisclosure.

FIG. 7 depicts an example process of an owner of a UBCDN of a blockchaininstance (a UBCDN owner), in accordance with implementations of thepresent disclosure.

FIG. 8 depicts an example process of a relay for cross-chaininteractions in a unified blockchain network, in accordance withimplementations of the present disclosure.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Implementations of the present disclosure include computer-implementedmethods for a domain name scheme for blockchain systems. Moreparticularly, implementations of the present disclosure are directed tocross-chain interactions using a unified domain name scheme inblockchain systems.

In some implementations, actions include identifying, by a relay that iscommunicatively linked with a first blockchain instance and a secondblockchain instance in a unified blockchain network, a blockchain domainname of a first blockchain instance, wherein the blockchain domain nameof the second blockchain instance is a unique identifier of the secondblockchain instance and uniquely corresponds to a chain identifier ofthe second blockchain instance in the unified blockchain network;identifying a blockchain domain name of the second blockchain instance,wherein the blockchain domain name of the first blockchain instance is aunique identifier of the first blockchain instance and uniquelycorresponds to a chain identifier of the first blockchain instance inthe unified blockchain network; receiving, from a node of the firstblockchain instance, an access request for accessing the secondblockchain instance, wherein the access request including the blockchaindomain name of the second blockchain instance; identifying the chainidentifier of the second blockchain instance based on the blockchaindomain name of the second blockchain instance, wherein the chainidentifier of the second blockchain instance indicates a blockchainnetwork configuration of the second blockchain instance; and providingaccess to the second blockchain instance for the first blockchaininstance based on the blockchain network configuration indicated by thechain identifier of the second blockchain instance.

To provide further context for implementations of the present disclosureand, as introduced above, distributed ledger systems (DLSs), which canalso be referred to as consensus networks (e.g., made up of peer-to-peernodes), and blockchain networks, enable participating entities tosecurely, and immutably conduct transactions, and store data. Althoughthe term blockchain is generally associated with the Bitcoincrypto-currency network, blockchain is used herein to generally refer toa DLS without reference to any particular use case. As introduced above,a blockchain network can be provided as a public blockchain network, aprivate blockchain network, or a consortium blockchain network.

In a public blockchain network, the consensus process is controlled bynodes of the consensus network. For example, hundreds, thousands, evenmillions of entities can cooperate a public blockchain network, each ofwhich operates at least one node in the public blockchain network.Accordingly, the public blockchain network can be considered a publicnetwork with respect to the participating entities. In some examples, amajority of entities (nodes) must sign every block in order for theblock to be valid, and added to the blockchain (distributed ledger) ofthe blockchain network. An example public blockchain network includesthe Bitcoin network, which is a peer-to-peer payment network. TheBitcoin network leverages a distributed ledger, referred to asblockchain. As noted above, the term blockchain, however, is used togenerally refer to distributed ledgers without particular reference tothe Bitcoin network.

In general, a public blockchain network supports public transactions. Apublic transaction is shared with all of the nodes within the publicblockchain network, and is stored in a global blockchain. A globalblockchain is a blockchain that is replicated across all nodes. That is,all nodes are in perfect state consensus with respect to the globalblockchain. To achieve consensus (e.g., agreement to the addition of ablock to a blockchain), a consensus protocol is implemented within thepublic blockchain network. An example consensus protocol includes,without limitation, proof-of-work (POW) implemented in the Bitcoinnetwork.

In general, a private blockchain network is provided for a particularentity, which centrally controls read and write permissions. The entitycontrols, which nodes are able to participate in the blockchain network.Consequently, private blockchain networks are generally referred to aspermissioned networks that place restrictions on who is allowed toparticipate in the network, and on their level of participation (e.g.,only in certain transactions). Various types of access controlmechanisms can be used (e.g., existing participants vote on adding newentities, a regulatory authority can control admission).

In general, a consortium blockchain network is private among theparticipating entities. In a consortium blockchain network, theconsensus process is controlled by an authorized set of nodes, one ormore nodes being operated by a respective entity (e.g., a financialinstitution, insurance company). For example, a consortium of ten (10)entities (e.g., financial institutions, insurance companies) can operatea consortium blockchain network, each of which operates at least onenode in the consortium blockchain network. Accordingly, the consortiumblockchain network can be considered a private network with respect tothe participating entities. In some examples, each entity (node) mustsign every block in order for the block to be valid, and added to theblockchain. In some examples, at least a sub-set of entities (nodes)(e.g., at least 7 entities) must sign every block in order for the blockto be valid, and added to the blockchain.

Implementations of the present disclosure are described in furtherdetail herein with reference to a consortium blockchain network. It iscontemplated, however, that implementations of the present disclosurecan be realized in any appropriate type of blockchain network.

Implementations of the present disclosure are described in furtherdetail herein in view of the above context. More particularly, and asintroduced above, implementations of the present disclosure are directedto a domain name scheme for cross-chain interactions in blockchainsystems.

Various blockchain platforms, environments, or products have beendeveloped based on different blockchain technologies. Example blockchainproducts include Ethereum and Bitcoin. The current blockchain networkincludes multiple blockchain instances deployed based on the differentblockchain products. For example, the current blockchain networkincludes various blockchain instances such as public blockchains,private blockchains, or consortium blockchains that are developed basedon Ethereum or Bitcoin technologies.

The current access mode of each blockchain instance requires access froma client node (also referred to as a client terminal) of the blockchainor its technical components such as SDKs. In order to accurately connectto a specific blockchain instance, the client needs to load itsblockchain network configurations. These blockchain networkconfigurations are typically hash, member certificates, etc. Theseconfigurations are unreadable to humans and it is difficult to identifywhich chains the configurations identify.

The present disclosure provides a domain name scheme for the blockchainnetwork. Specifically, a unified blockchain domain name (UBCDN) isprovided to serve as a unique identifier of each blockchain instance(also referred to as a blockchain network instance or a chain) in theblockchain network. A blockchain instance can be, for example, animplementation or deployment of a blockchain based on a blockchainplatform or technology (e.g., Ethereum). Each UBCDN uniquely binds adomain name of a blockchain instance (also referred to as a blockchaindomain name) with a corresponding network configuration of theblockchain instance (also referred to as a blockchain networkconfiguration). In some implementations, the blockchain networkconfiguration can be represented or indicated by a chain identifier. Aclient node of a blockchain instance can obtain a correspondingblockchain network configuration by parsing the UBCDN to identify thechain identifier. Based on the blockchain network configuration, theclient node can link to, or otherwise access, to the specific blockchaininstance.

The described domain name scheme can provide a unified protocol forinteractions between blockchain systems in a unified (or global)blockchain network that includes multiple or all blockchain instancesdeployed, based on different blockchain products or technologies. Allblockchain instances in the unified blockchain network follow the samedomain name scheme and be assigned unique UBCDNs. In someimplementations, each blockchain instance in the unified blockchainnetwork is assigned a single UBCDN that can be recognized by all theblockchain instances in the unified blockchain network, regardless ofdifferent platforms, technologies, or relays that are used in theunified blockchain network. In some implementations, the UBCDN defines arealm of administrative autonomy, authority or control of a blockchaininstance within the unified blockchain network. In some implementations,the unified blockchain network can be regarded as a counterpart of theInternet in the IP network, while the UBCDN can be regarded as a mappingof a domain name of an IP resource in the IP network with an IP addressof the IP resource.

Each blockchain instance in the unified blockchain network can beuniquely identified by a corresponding UBCDN so as to facilitatemulti-chain or cross-chain communications. For example, unlike existingcross-chain implementations such as COSMOS, that uses a relay chain forcross-chain interactions, in which each blockchain is assigned anidentifier (ID) within the relay chain network but the ID only has alocal scope and cannot be reused in other relay chain networks, in thedescribed domain name scheme, the UBCDN can be used and is recognizableglobally by all blockchain instances in the unified blockchain network,despite how many relay chains are included in the unified blockchainnetwork.

Moreover, the described domain name scheme simplifies the identificationor addressing protocol for cross-chain interactions in blockchainsystems. For example, in the described domain name scheme, a singleUBCDN is sufficient to uniquely identify a blockchain instance and isrecognizable globally by all blockchain instances in the unifiedblockchain network for interactions among different blockchain networks,whereas in COSMOS a blockchain instance is assigned multiple differentIDs when the blockchain instance joins multiple relay chains for theblockchain instance to interact with other blockchains.

Furthermore, the UBCDN can include a human-readable identifier or label,helping users to memorize and reach a blockchain instance easily, andthus promoting adoption or use of the blockchain instance. As anexample, owners or operators of public blockchains, private blockchains,or consortium blockchains can choose blockchain domain names thatcorrespond to their names, helping users to remember the identifiers ofthe blockchain instances, and further facilitating translation,resolution, or otherwise identification of the chain identifierscorresponding to the blockchain domain names, expediting cross-chaininteractions in the unified blockchain network.

Besides providing easily recognizable and memorizable names to identifyblockchain instances, the UBCDN allows a blockchain instance to keep itsblockchain domain name even though the underlying network configurationof the blockchain instance is changed (for example, by system updatingor moving or migrating to a different physical location in the addresstopology of the network). In the event of such a change or update, thechain identifier of the blockchain instance can be changed while theblockchain domain name can remain the same. The UBCDN owner can changethe mapping of the blockchain domain name to the updated chainidentifier and allow others (e.g., other blockchain instances or clientnodes) to use the same blockchain domain name to address and access theblockchain instance.

FIG. 1 depicts an example environment 100 that can be used to executeimplementations of the present disclosure. In some examples, the exampleenvironment 100 enables entities to participate in a consortiumblockchain network 102. The example environment 100 includes computingdevices or systems 106, 108, and a network 110. In some examples, thenetwork 110 includes a local area network (LAN), wide area network(WAN), the Internet, or a combination thereof, and connects web sites,user devices (e.g., computing devices), and back-end systems. In someexamples, the network 110 can be accessed over a wired and/or a wirelesscommunications link.

In the depicted example, the computing systems 106, 108 can each includeany appropriate computing system that enables participation as a node inthe consortium blockchain network 102. Example computing devicesinclude, without limitation, a server, a desktop computer, a laptopcomputer, a tablet computing device, and a smartphone. In some examples,the computing systems 106, 108 hosts one or more computer-implementedservices for interacting with the consortium blockchain network 102. Forexample, the computing system 106 can host computer-implemented servicesof a first entity (e.g., user A), such as a transaction managementsystem that the first entity uses to manage its transactions with one ormore other entities (e.g., other users). The computing system 108 canhost computer-implemented services of a second entity (e.g., user B),such as a transaction management system that the second entity uses tomanage its transactions with one or more other entities (e.g., otherusers). In the example of FIG. 1, the consortium blockchain network 102is represented as a peer-to-peer network of nodes, and the computingsystems 106, 108 provide nodes of the first entity, and second entityrespectively, which participate in the consortium blockchain network102.

FIG. 2 depicts an example conceptual architecture 200 in accordance withimplementations of the present disclosure. The example conceptualarchitecture 200 includes an entity layer 202, a hosted services layer204, and a blockchain network layer 206. In the depicted example, theentity layer 202 includes three entities, Entity_1 (E1), Entity_2 (E2),and Entity_3 (E3), each entity having a respective transactionmanagement system 208.

In the depicted example, the hosted services layer 204 includesinterfaces 210 for each transaction management system 208. In someexamples, a respective transaction management system 208 communicateswith a respective interface 210 over a network (e.g., the network 110 ofFIG. 1) using a protocol (e.g., hypertext transfer protocol secure(HTTPS)). In some examples, each interface 210 provides a communicationconnection between a respective transaction management system 208, andthe blockchain network layer 206. More particularly, the interface 210communicates with a blockchain network 212 of the blockchain networklayer 206. In some examples, communication between an interface 210, andthe blockchain network layer 206 is conducted using remote procedurecalls (RPCs). In some examples, the interfaces 210 “host” blockchainnetwork nodes for the respective transaction management systems 208. Forexample, the interfaces 210 provide the application programminginterface (API) for access to blockchain network 212.

As described herein, the blockchain network 212 is provided as apeer-to-peer network including a number of nodes 214 that immutablyrecord information in a blockchain 216. Although a single blockchain 216is schematically depicted, multiple copies of the blockchain 216 areprovided, and are maintained across the blockchain network 212. Forexample, each node 214 stores a copy of the blockchain. In someimplementations, the blockchain 216 stores information associated withtransactions that are performed between two or more entitiesparticipating in the consortium blockchain network.

FIG. 3 depicts an example unified blockchain domain name (UBCDN) 300 ofa blockchain instance, in accordance with implementations of the presentdisclosure. The UBCDN 300 can include a blockchain domain name 310 and acorresponding chain identifier 320 of the blockchain instance. Theblockchain domain name 310 can be human-readable label. The chainidentifier 320 can indicate a blockchain network configuration of theblockchain instance and allow access to the blockchain instance based onthe blockchain network configurations. In some implementations, theUBCDN 300 can include additional fields or be represented as a string oranother data structure.

The blockchain domain name 310 can be user-friendly. For example, theblockchain domain name 310 can be a text-based label that is easier tomemorize than the corresponding numerical chain identifier 320 (e.g., a40 character hex address used in the Ethereum protocols. In someimplementations, the blockchain domain name 310 can be represented as astring or another data structure.

In some implementations, the blockchain domain name 310 can have definedsyntax to further facilitate understanding of the source, ownership, ororganization of the underlying blockchain instance. For example, theblockchain domain name 310 can be designed in a similar manner to thedomain name in the IP network. The blockchain domain name 310 caninclude one or more parts or labels. The one or more labels can beconcatenated and have a hierarchy of domains descending from the rightto the left label in the name. Each label to the left specifies asubdivision or subdomain of the domain to the right. For example, ablockchain domain name 310 of chain1. organization1 indicates that theunderlying blockchain instance chain1 is a subdomain of theorganization1 domain and belongs to the organization1. In someimplementations, the blockchain domain name 310 can define additional ordifferent syntax.

The chain identifier 320 can include an addressable identifier that isused to address and access the blockchain instance in the blockchainnetwork. The chain identifier 320 can indicate a blockchain networkconfiguration of the blockchain instance and allow access to theblockchain instance based on the blockchain network configurations. Forexample, multiple blockchain instances can be deployed based on Ethereumtechnology. The blockchain instance can be, for example, a mainnetchain, a testing chain, a private chain, or a consortium chain. AnEthereum client can establish a connection with an Ethereum blockchaininstance by loading the genesis block (i.e., the first block) of theEthereum blockchain instance. The genesis block is equivalent to aunique identifier of the Ethereum blockchain instance. Accordingly, insome implementations, one or more fields (e.g., a hash value) of thegenesis block of an Ethereum blockchain instance can be extracted as thechain identifier 320 of the Ethereum blockchain instance. In someimplementations, the chain identifier of a blockchain instance caninclude a hash value of a genesis block of the blockchain instance, aswell as a network ID that identifies the blockchain instance. In someimplementations, the network ID allows transactions on the blockchaininstance to look different from those on other chains, for example, bysigning transactions differently, depending on the network ID used. Assuch, the network ID indicates additional network configuration that canbe used to link to or otherwise access the blockchain instance. Thechain identifier 320 can include additional or different components orfields, for example, depending on the underlying blockchain technologyor platform of the blockchain instance.

The UBCDN 300 creates a one-to-one mapping of the blockchain domain name310 and its corresponding chain identifier 320 of the blockchaininstance. Given the blockchain domain name 310, its corresponding chainidentifier 320 can be translated, resolved, or otherwise identified, andvice versa. As such, a node can access the blockchain instance based onthe blockchain network configuration indicated by the chain identifier320. As an analogy, the blockchain domain name 310 of a blockchaininstance is similar to a domain name according to the Domain Name System(DNS) of an Internet Protocol (IP) resource (e.g., example.com) and thechain identifier 320 is similar to the IP address of the IP resource inthe IP network.

In some implementations, for a given blockchain domain name 310, itscorresponding chain identifier 320 can be translated, resolved orotherwise identified using UBCDN look-up information that is cached orotherwise stored either locally, inside a querying computer, or remotelyin the unified blockchain network (e.g., in a central UBCDN server). TheUBCDN look-up information can include multiple UBCDN 300, each UBCDN 300corresponding to multiple blockchain instances. The UBCDN look-upinformation can be stored, for example, in a look-up table or anotherdata structure. One or more nodes (e.g., a client node, a consensusnode, or a relay node) or a server in the unified blockchain network canstore UBCDN look-up information. By searching based on UBCDN look-upinformation, a chain identifier 320 corresponding to a given blockchaindomain name 310 can be identified, and vice versa.

When UBCDN information is cached locally, the UBCDN look-up process canbe quicker than performing a remote UBCDN look-up, for example, at aremote UBCDN server. In some implementations, in the latter remote UBCDNlook-up, a user inputs a blockchain domain name 310, e.g.,“chain1.organization1” into an SDK of the computing device of the user(i.e., the client node). The client node sends a request or query thatincludes the blockchain domain name 310 “chain1.organization1” to aremote UBCDN server, for example, through the Internet off the chain.Upon receiving the request, the remote UBCDN server searches in theUBCDN look-up information for an entry matching the blockchain domainname 310 “chain1.organization1” and identifies the chain identifier 320corresponding to the blockchain domain name 310. Then the remote UBCDNserver responds to the client node with the chain identifier 320corresponding to the blockchain domain name 310, for example, by sendinga response including the chain identifier 320 corresponding to theblockchain domain name 310 to the client node.

FIG. 4 depicts an example UBCDN management scheme 400 in a unifiedblockchain network, in accordance with implementations of the presentdisclosure. The example UBCDN management scheme 400 can provide enhancedtrust and security for cross-chain communications based on the UBCDN. Insome implementations, the example UBCDN management scheme 400 relies ona public key infrastructure (PKI) to establish trust in the unifiedblockchain network.

For example, a certificate authority (CA) 410 (e.g., the operator of thePKI) can be used. The CA 410 issues a domain certificate (“Domain Cert”)420 a, 420 b, and 420 c (collectively, domain certificate 420) to eachowner of a UBCDN 430 a, 430 b, and 430 c (collectively, UBCDN owner430). The UBCDN owner 430 can be, for example, an owner or operator ofthe blockchain instance. As illustrated, the UBCDN owner 430 a is anowner of a blockchain domain name “Example1.chain,” the UBCDN owner 430b is an owner of a blockchain domain name “Example2.chain,” and theUBCDN owner 430 b is an owner of a blockchain domain name“ExampleN.chain.”

In some implementations, the UBCDN owner 430 can obtain a domaincertificate 420 by applying to the CA 410 with a certificate signingrequest (not shown in FIG. 4). In some implementations, the certificaterequest is an electronic document that contains the blockchain domainname, information of the blockchain instance (e.g., the chain identifieror other network configurations), and a public key of the UBCDN owner430. Upon verification that the UBCDN owner 430 has the right toadministratively manage the blockchain domain name of the blockchaininstance, the CA 410 can sign the request, thus producing a publicdomain certificate 420. In some implementations, the domain certificate420 can be served to any node (e.g., a client node, a consensus node, ora relay node) that would like to access the underlying blockchaininstance of the blockchain domain name (e.g., “Example1.chain”) andproves to the node that the CA 410 trusts and has issued a certificateto the UBCDN owner 430.

The domain certificate 420 can include a blockchain domain name (e.g.,“Example1.chain”) and a public key of the UBCDN owner 430. The UBCDNowner 430 is the private key holder corresponding to the public key. TheCA 410 can digitally sign the blockchain domain name and the public keyof the UBCDN owner 430 using the CA's own private key. The domaincertificate 420 can include the digital signature signed by the CA 410on the blockchain domain name and the public key of the UBCDN owner 430.

As described with respect to FIG. 3, a UBCDN can include a blockchaindomain name (e.g., “Example1.chain”) and a corresponding chainidentifier. The UBCDN owner 430 can publish the UBCDN and sign the UBCDNusing the private key of the UBCDN owner 430. In some implementations,the UBCDN owner 430 publishes one or more UBCDN messages (e.g., UBCDNmessages 440 a, 450 a, 440) so that the UBCDN can be authenticated orverified.

In some implementations, the UBCDN messages 440 can include the UBCDN, adigital signature of the UBCDN resulting, and a domain certificate. Thedomain certificate can be the respective domain certificate 420 receivedfrom the CA 410. The UBCDN can include the blockchain domain name andthe chain identifier (e.g., the blockchain domain name 310 and the chainidentifier 320, as described with respect to FIG. 3). As illustrated,the UBCDN owner 430 a issues a UBCDN message 440 a that includes theblockchain domain name 442 a “Example1.chain” and a corresponding chainidentifier 444 a “Chain Identifier V0,” a digital signature 446 a, and adomain certificate 448 a. The domain certificate 448 a can be the domaincertificate 420 a issued by the CA 410 and received by the UBCDN owner430 a from the CA 410. The digital signature 446 a can result from theUBCDN owner 430 a's signing of the UBCDN (that is, the blockchain domainname 442 a “Example1.chain” and a corresponding chain identifier 444 a“Chain Identifier V0” in this case) using the UBCDN owner 430 a'sprivate key.

Similarly, the UBCDN owner 430 b issues a UBCDN message 440 b thatincludes the blockchain domain name 442 b “Example2.chain” and acorresponding chain identifier 444 b “Chain Identifier Vx,” a digitalsignature 446 b, and a domain certificate 448 b. The domain certificate448 b can be the domain certificate 420 b issued by the CA 410 andreceived by the UBCDN owner 430 b from the CA 410. The digital signature446 a can result from the UBCDN owner 430 b's signing of the UBCDN (thatis, the blockchain domain name 442 b “Example2.chain” and acorresponding chain identifier 444 a “Chain Identifier V0” in this case)using the UBCDN owner 430 b's private key.

In some implementations, an authentication or verification process canbe performed, for example, by any node in the unified blockchain networkor a third party to verify the validity of a UBCDN based on the UBCDNmessage. This can ensure security that is important for electroniccommerce, especially in connection with mobile payment transactions forcross-chain interactions in blockchain systems.

In some implementations, the authentication or verification process caninclude, for example, verifying that the blockchain domain name is thesame as the blockchain domain name in the domain certificate; verifyingthat the UBCDN owner (e.g., the UBCDN owner 430 a) is the holder of theblockchain domain name (e.g., “the blockchain domain name 442 a“Example1.chain”) by verifying the digital signature on the UBCDN (e.g.,the digital signature 446 a) using the public key in the domaincertificate (e.g., the domain certificate 420 a) issued by the CA 410,and verifying that the domain certificate (e.g., the domain certificate448 a) is issued by the trusted CA 410.

In some implementations, after verifying the validity of the UBCDN, forexample, based on the authentication or verification process, a clientnode can use the UBCDN for cross-chain interactions in the unifiedblockchain network. For example, the client node can receive and read aUBCDN message, verify the validity or legality of UBCDN and confirm thatthe UBCDN is issued by the owner of the UBCDN; and then use the UBCDN touniquely identify and access the blockchain instance, for example, byidentifying the chain identifier corresponding to the blockchain domainname in the UBCDN.

FIG. 5 depicts an example process 500 for using a blockchain domain nameof a blockchain instance for cross-chain interactions in a unifiedblockchain network, in accordance with implementations of the presentdisclosure. In some implementations, the example process 500 may beperformed using one or more computer-executable programs executed usingone or more computing devices. For clarity of presentation, thedescription that follows generally describes process 500 in the contextof the other figures in this description. For example, the exampleprocess 500 can be executed by a client node of a first blockchaininstance, such as, the computing system 106 or 108 of the consortiumblockchain network 102 as described with respect to FIG. 1, or the node214 of the blockchain network 212 as described with respect to FIG. 2.However, it will be understood that process 500 may be performed, forexample, by any suitable system, environment, software, and hardware, ora combination of systems, environments, software, and hardware, asappropriate. In some implementations, various steps of process 500 canbe run in parallel, in combination, in loops, or in any order.

At 510, a client node of a first blockchain instance obtains ablockchain domain name of a second, different blockchain instance. Insome implementations, the first blockchain instance and the secondblockchain instance are deployed based on different blockchainplatforms. In some implementations, the first blockchain instance andthe second blockchain instance belong to different owners or operators.The first blockchain instance and the second blockchain instance are ina unified blockchain network including a number of blockchain instancesthat are communicatively linked by two or more relays.

The blockchain domain name is a unique identifier of the secondblockchain instance in the unified blockchain network, even though theunified blockchain network includes two or more relays. In someimplementations, each of the number of blockchain instances in theunified blockchain network has only one blockchain domain name thatuniquely identifies the each of the number of blockchain instances inthe unified blockchain network.

The blockchain domain name includes a human-readable label. In someimplementations, the human-readable label includes a text-based label.The blockchain domain name uniquely corresponds to a chain identifier ofthe second blockchain instance. The blockchain domain name and the chainidentifier can be represented by a UBCDN such as UBCDN 300, as describedin FIG. 3. As an example, the blockchain domain name can be theblockchain domain name 310, while the chain identifier can be thecorresponding chain identifier 320 in the UBCDN 300.

At 520, the client node of the first blockchain instance identifies thechain identifier of the second blockchain instance based on theblockchain domain name of the second blockchain instance, wherein thechain identifier of the second blockchain instance indicates ablockchain network configuration of the second blockchain instance. Insome implementations, the chain identifier of the second blockchaininstance includes a hash value of a genesis block of the secondblockchain instance and a network identifier of the second blockchaininstance, for example, as described within respect to FIG. 3.

In some implementations, identifying the chain identifier of the secondblockchain instance based on the blockchain domain name includesidentifying the chain identifier of the second blockchain instanceaccording to look-up information locally stored at the client node basedon the blockchain domain name.

In some implementations, identifying the chain identifier of the secondblockchain instance based on the blockchain domain name includesidentifying the chain identifier of the second blockchain instance froma remote unified blockchain domain name server based on the blockchaindomain name. For example, the client node of the first blockchaininstance sends a request or query to the unified blockchain domain nameserver. The request includes the blockchain domain name for identifyingthe chain identifier of the second blockchain instance. Then the clientnode of the first blockchain instance receives, from the unifiedblockchain domain name server, a response to the request, wherein theresponse includes the chain identifier of the second blockchaininstance.

At 530, the client node of the first blockchain instance accesses thesecond blockchain instance based on the blockchain network configurationindicated by the chain identifier of the second blockchain instance. Forexample, the first blockchain instance accesses the second blockchaininstance via a client node of the second blockchain instance based onthe hash value of the genesis block of the second blockchain instanceindicated by the chain identifier of the second blockchain instance. Insome implementations, the first blockchain instance accesses the secondblockchain instance via a client node of the second blockchain by usinga relay (e.g., a relay node or a relay chain) or other application thatthat is communicatively linked to both the first blockchain instance andthe second blockchain instance.

In some implementations, to access and obtain data from the secondblockchain instance, the client node of the second blockchain instancecan configure a network configuration such as an IP address and a portnumber of a node (e.g., a consensus node) of the second blockchain, andthe hash value of the genesis block of the second blockchain instance.The client node of the second blockchain instance can connect to thenode of the second blockchain instance through the IP address and theport number of the node of the second blockchain instance. The clientnode of the second blockchain instance can read, retrieve, download, orotherwise obtain the data of the node of the second blockchain instanceand verify whether the obtained data come from the second blockchaininstance, for example, based on a Simple Payment Verification (SPV)protocol of the second blockchain instance to determine whether theobtained data point to the hash value of the genesis block of the secondblockchain instance.

At 540, the client node of the first blockchain instance performscross-chain transactions between the first blockchain instance and thesecond blockchain instance based on the blockchain domain name of thesecond blockchain instance. In some implementations, performingcross-chain transactions between the first blockchain instance and thesecond blockchain instance includes sending, by the first blockchaininstance, a cross-chain request that includes blockchain domain name ofthe second blockchain instance and a data request, to a relay that iscommunicatively linked to both the first blockchain instance and thesecond blockchain instance. The relay receives the cross-chain requestand reads the blockchain domain name of the second blockchain instance,loads the corresponding blockchain network configuration of the secondblockchain instance, uses the configuration to connect to the secondblockchain instance. The rely can retrieve, download, or otherwisereceive the requested data from the second blockchain instance, and sendthe requested data to the first blockchain instance.

FIG. 6 depicts an example process 600 for authenticating a UBCDN of ablockchain instance, in accordance with implementations of the presentdisclosure. In some implementations, the example process 600 may beperformed using one or more computer-executable programs executed usingone or more computing devices. For clarity of presentation, thedescription that follows generally describes process 600 in the contextof the other figures in this description. For example, the exampleprocess 600 that can be executed by the computing system 106 or 108 ofthe consortium blockchain network 102, as described with respect to FIG.1, or the node 214 of the blockchain network 212, as described withrespect to FIG. 2. However, it will be understood that process 600 maybe performed, for example, by any suitable system, environment,software, and hardware, or a combination of systems, environments,software, and hardware, as appropriate. In some implementations, varioussteps of process 600 can be run in parallel, in combination, in loops,or in any order.

At 610, a computing system obtains a unified blockchain domain name(UBCDN) message of a blockchain instance. In some implementations, thecomputing system is a third party of unified blockchain network. In someimplementations, the computing system is a client node of a secondblockchain instance different from the blockchain instance in theunified blockchain network.

The UBCDN message can be, for example, the UBCDN message 440 asdescribed with respect to FIG. 4. The UBCDN message includes a UBCDN ofthe blockchain instance, a digital signature of an UBCDN owner on theUBCDN; and a domain certificate of the UBCDN.

The UBCDN of the blockchain instance includes a blockchain domain nameof the blockchain instance, wherein the blockchain domain name is aunique identifier of the blockchain instance in a unified blockchainnetwork including a number of blockchain instances that arecommunicatively linked by two or more relays. The blockchain domain nameincludes a human-readable label and a chain identifier of the blockchaininstance uniquely corresponding to the blockchain domain name.

In some implementations, the domain certificate of the UBCDN includesthe blockchain domain name of the blockchain instance, the public key ofthe UBCDN owner, and a digital signature of the CA on the blockchaindomain name of the blockchain instance and the public key of the UBCDNowner.

At 620, the computing system verifies whether the domain certificate ofthe UBCDN is issued by a trusted certificate authority (CA) using apublic key of the CA. In some implementations, the digital signature ofthe CA is obtained by the CA signing on the blockchain domain name ofthe blockchain instance and the public key of the UBCDN owner using aprivate key of the CA corresponding to the public key of the CA. In someimplementations, verifying whether the domain certificate of the UBCDNis issued by a trusted CA using a public key of the CA includesverifying that the domain certificate of the UBCDN is issued by the CAusing the domain certificate, the digital signature of the CA, and thepublic key of the CA.

At 630, in response to verifying that the domain certificate of theUBCDN is issued by the CA, the computing system verifies whether theUBCDN is issued by the UBCDN owner using a public key of the UBCDNowner. In some implementations, the digital signature of the owner ofthe UBCDN is obtained by the owner of the UBCDN singing the UBCDN usinga private key corresponding to the public key of the owner of the UBCDN.In some implementations, verifying whether the UBCDN of the blockchaininstance is issued by the UBCDN owner using a public key of the owner ofthe UBCDN includes verifying that the UBCDN is issued by the owner ofthe UBCDN using the UBCDN, the digital signature of the owner of theUBCDN, and the public key of the owner of the UBCDN. For example, theowner of the UBCDN can sign the UBCDN using the owner's private key andgenerate a digital signature, for example, according to a signingalgorithm. The computing system as a recipient of the UBCDN message candetermine whether the UBCDN is issued by the UBCDN owner using theUBCDN, the digital signature, and the public key of the owner, forexample, according to a signature verifying algorithm.

At 640, in response to verifying that the UBCDN is issued by the UBCDNowner, the computing system performs cross-chain transactions betweenthe blockchain instance and the second blockchain instance based on theblockchain domain name of the blockchain instance, for example,according to the example process 500 as described with respect to FIG.5.

FIG. 7 depicts an example process 700 of an owner of a UBCDN of ablockchain instance (a UBCDN owner), in accordance with implementationsof the present disclosure. In some implementations, the example process700 may be performed using one or more computer-executable programsexecuted using one or more computing devices. For clarity ofpresentation, the description that follows generally describes process700 in the context of the other figures in this description. Forexample, the example process 700 can be executed by the UBCDN owner 430as described with respect to FIG. 4. However, it will be understood thatprocess 700 may be performed, for example, by any suitable system,environment, software, and hardware, or a combination of systems,environments, software, and hardware, as appropriate. In someimplementations, various steps of process 700 can be run in parallel, incombination, in loops, or in any order.

At 710, an owner of a UBCDN of a blockchain instance (a UBCDN owner,such as the UBCDN owner 430) obtains, from a trusted certificateauthority (CA) (e.g., the CA 410), a domain certificate (e.g., thedomain certificate 420) of the UBCDN of the blockchain instance. TheUBCDN of the blockchain instance includes a blockchain domain name ofthe blockchain instance and a chain identifier of the blockchaininstance uniquely corresponding to the blockchain domain name. The UBCDNcan be, for example, the UBCDN 300, as described with respect to FIG. 3.The blockchain domain name is a unique identifier of the blockchaininstance in a unified blockchain network including a number ofblockchain instances that are communicatively linked by two or morerelays. In some implementations, the blockchain domain name includes ahuman-readable label. The chain identifier indicates a blockchainnetwork configuration of the blockchain instance.

The domain certificate of the UBCDN includes the blockchain domain nameof the blockchain instance, a public key of the UBCDN owner, and adigital signature of the CA on the blockchain domain name of theblockchain instance and the public key of the UBCDN owner. The domaincertificate of the UBCDN can be, for example, the domain certificate420, as described with respect to FIG. 4.

At 720, the UBCDN owner signs the UBCDN of the blockchain instance, forexample, using the private key of the UBCDN owner, for example,according to a signing algorithm.

At 730, the UBCDN owner publishes a UBCDN message (e.g., the UBCDNmessage 440 a or 440 b) of the blockchain instance. The UBCDN messageincludes the UBCDN of the blockchain instance, a digital signature ofthe UBCDN owner resulting from the signing the UBCDN, and the domaincertificate of the UBCDN.

At 740, the UBCDN owner identifies an updated chain identifier of theblockchain instance indicating an updated blockchain networkconfiguration of the blockchain instance. For example, a change orupdate of the blockchain network configuration of the blockchaininstance can occur (e.g., due to system update or move of the physicallocation of one or more computing device such as the genesis block). Thechain identifier can be updated to reflect the update of the blockchainnetwork configuration of the blockchain instance (e.g., by updating thehash value of the genesis block of the blockchain instance). Forexample, as illustrated in FIG. 4, for the same blockchain domain name442 a “Example1.chain,” the chain identifier 444 a “Chain Identifier V0”has been updated to a chain identifier 454 a “Chain Identifier V1”, toreflect the change of the blockchain network configuration of theblockchain instance.

At 750, the UBCDN owner signs an updated UBCDN of the blockchaininstance, for example, using the private key of the UBCDN owner. Theupdated UBCDN of the blockchain instance includes the blockchain domainname of the blockchain instance and the updated chain identifier of theblockchain instance. For example, as illustrated in FIG. 4, the updatedUBCDN of the blockchain instance includes the same blockchain domainname 442 a “Example1.chain” and the updated chain identifier 454 a“Chain Identifier V1.”

At 760, the UBCDN owner publishes an updated UBCDN message of theblockchain instance. The updated UBCDN message includes the updatedUBCDN of the blockchain instance, an updated digital signature of theUBCDN owner resulting from the signing the updated UBCDN, and the domaincertificate of the UBCDN. For example, as illustrated in FIG. 4, theUBCDN owner 430 a issues an updated UBCDN messages 450 a that includesthe blockchain domain name 442 a “Example1.chain” and the updated chainidentifier 454 a “Chain Identifier V1,” a digital signature 456 a, and adomain certificate 458 a. The domain certificate 458 a can be the domaincertificate 420 a issued by the CA 410 and received by the UBCDN owner430 a from the CA 410. The updated digital signature 456 a can resultfrom the UBCDN owner 430 a's signing of the updated UBCDN (that is, theblockchain domain name 442 a “Example1.chain” and the updated chainidentifier 454 a “Chain Identifier V0” in this case) using the UBCDNowner 430 a's private key.

FIG. 8 depicts an example process 800 of a relay for cross-chaininteractions in a unified blockchain network, in accordance withimplementations of the present disclosure. The unified blockchainnetwork includes a number of blockchain instances that arecommunicatively linked by two or more relays. In some implementations,the example process 800 may be performed using one or morecomputer-executable programs executed using one or more computingdevices. For clarity of presentation, the description that followsgenerally describes process 800 in the context of the other figures inthis description. For example, the example process 800 that can beexecuted by the relay in a unified blockchain network. However, it willbe understood that process 800 may be performed, for example, by anysuitable system, environment, software, and hardware, or a combinationof systems, environments, software, and hardware, as appropriate. Forexample, the relay can be a node (e.g., the computing system 106 or 108as described with respect to FIG. 1 or the node 214 as described withrespect to FIG. 2), a blockchain instance (e.g., a blockchain network102 or the blockchain network 212), or another computer system in theunified blockchain network. In some implementations, various steps ofprocess 800 can be run in parallel, in combination, in loops, or in anyorder.

At 810, the relay that is communicatively linked with a first blockchaininstance and a second blockchain instance in the unified blockchainnetwork identifies a blockchain domain name of a first blockchaininstance. The blockchain domain name of the first blockchain instance isa unique identifier of the first blockchain instance and uniquelycorresponds to a chain identifier of the first blockchain instance inthe unified blockchain network. In some implementations, the blockchaindomain name of the first blockchain instance includes a firsthuman-readable label.

At 820, the relay identifies a blockchain domain name of the secondblockchain instance. The blockchain domain name of the second blockchaininstance is a unique identifier of the second blockchain instance anduniquely corresponds to a chain identifier of the second blockchaininstance in the unified blockchain network. In some implementations, theblockchain domain name of the second blockchain instance includes asecond human-readable label.

In some implementations, a relay can designate a local identifier foreach blockchain that is communicatively linked. The local identifier isdesignated for the use of the relay and cannot be used by other nodes orrelays in the unified blockchain network. In some implementations,identifying a blockchain domain name of the first blockchain instanceincludes using the blockchain domain name of the first blockchaininstance as the local identifier of the first blockchain instance orreplacing the local identifier of the first blockchain instance with theblockchain domain name of the first blockchain instance. Similarly,identifying a blockchain domain name of the second blockchain instanceincludes using the blockchain domain name of the second blockchaininstance as the local identifier of the second blockchain instance orreplacing the unique identifier of the second blockchain instance withthe blockchain domain name of the second blockchain instance.

At 830, the relay receives an access request for accessing the secondblockchain instance. The access request includes the blockchain domainname of the second blockchain instance.

At 840, the relay identifies the chain identifier of the secondblockchain instance based on the blockchain domain name of the secondblockchain instance. The chain identifier of the second blockchaininstance indicates a blockchain network configuration of the secondblockchain instance.

In some implementations, identifying the chain identifier of the secondblockchain instance based on the blockchain domain name of the secondblockchain instance includes identifying the chain identifier of thesecond blockchain instance according to look-up information locallystored at the relay based on the blockchain domain name.

In some implementations, identifying the chain identifier of the secondblockchain instance based on the blockchain domain name of the secondblockchain instance includes identifying the chain identifier of thesecond blockchain instance based on the blockchain domain name of thesecond blockchain instance from a remote unified blockchain domain nameserver.

At 850, the relay provides access to the second blockchain instance forthe first blockchain instance based on the blockchain networkconfiguration indicated by the chain identifier of the second blockchaininstance. In some implementations, the relay provides access to thesecond blockchain instance for the first blockchain instance accordingto a communication protocol designed for cross-chain interactions. Forexample, the relay can load the blockchain network configurationindicated by the chain identifier of the second blockchain instancecorresponding to the blockchain domain name of the second blockchaininstance. The relay uses the blockchain network configuration to connectto the second blockchain instance, obtains a result requested by thefirst blockchain instance from the second blockchain instance, andreturns the result requested by the first blockchain instance to thefirst blockchain instance, for example, according the example techniquesdescribed with respect to FIG. 5.

In some implementations, providing, by the relay, access to the secondblockchain instance for the first blockchain instance based on theblockchain network configuration indicated by the chain identifier ofthe second blockchain instance includes providing, by the relay, accessto the second blockchain instance for the first blockchain instance viaa second relay.

In some implementations, the blockchain network configuration indicatedby the chain identifier of the second blockchain instance is identifiedby the second relay based on the same chain identifier of the secondblockchain instance. In some implementations, the second blockchaininstance is accessed by the second relay based on the blockchain networkconfiguration indicated by the chain identifier of the second blockchaininstance. In other words, the first blockchain instance can use the samedomain name of the second blockchain instance, regardless of which relayis, or how many relays are, used to interact with the second blockchaininstance.

In some implementations, the blockchain network configuration indicatedby the chain identifier of the second blockchain instance is identifiedby the second relay according to look-up information locally stored atthe second relay based on the same chain identifier of the secondblockchain instance.

In some implementations, the blockchain network configuration indicatedby the chain identifier of the second blockchain instance is identifiedby the second relay based on the blockchain domain name of the secondblockchain instance from a remote unified blockchain domain name server.

The features described may be implemented in digital electroniccircuitry, or in computer hardware, firmware, software, or incombinations of them. The apparatus may be implemented in a computerprogram product tangibly embodied in an information carrier (e.g., in amachine-readable storage device) for execution by a programmableprocessor; and method steps may be performed by a programmable processorexecuting a program of instructions to perform functions of thedescribed implementations by operating on input data and generatingoutput. The described features may be implemented advantageously in oneor more computer programs that are executable on a programmable systemincluding at least one programmable processor coupled to receive dataand instructions from, and to transmit data and instructions to, a datastorage system, at least one input device, and at least one outputdevice. A computer program is a set of instructions that may be used,directly or indirectly, in a computer to perform a certain activity orbring about a certain result. A computer program may be written in anyform of programming language, including compiled or interpretedlanguages, and it may be deployed in any form, including as astand-alone program or as a module, component, subroutine, or other unitsuitable for use in a computing environment.

Suitable processors for the execution of a program of instructionsinclude, by way of example, both general and special purposemicroprocessors, and the sole processor or one of multiple processors ofany kind of computer. Generally, a processor will receive instructionsand data from a read-only memory or a random access memory or both.Elements of a computer may include a processor for executinginstructions and one or more memories for storing instructions and data.Generally, a computer may also include, or be operatively coupled tocommunicate with, one or more mass storage devices for storing datafiles; such devices include magnetic disks, such as internal hard disksand removable disks; magneto-optical disks; and optical disks. Storagedevices suitable for tangibly embodying computer program instructionsand data include all forms of non-volatile memory, including by way ofexample semiconductor memory devices, such as EPROM, EEPROM, and flashmemory devices; magnetic disks such as internal hard disks and removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Theprocessor and the memory may be supplemented by, or incorporated in,application-specific integrated circuits (ASICs).

To provide for interaction with a user, the features may be implementedon a computer having a display device such as a cathode ray tube (CRT)or liquid crystal display (LCD) monitor for displaying information tothe user and a keyboard and a pointing device such as a mouse or atrackball by which the user may provide input to the computer.

The features may be implemented in a computer system that includes aback-end component, such as a data server, or that includes a middlewarecomponent, such as an application server or an Internet server, or thatincludes a front-end component, such as a client computer having agraphical user interface or an Internet browser, or any combination ofthem. The components of the system may be connected by any form ormedium of digital data communication such as a communication network.Examples of communication networks include, e.g., a local area network(LAN), a wide area network (WAN), and the computers and networks formingthe Internet.

The computer system may include clients and servers. A client and serverare generally remote from each other and typically interact through anetwork, such as the described one. The relationship of client andserver arises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherimplementations are within the scope of the following claims.

A number of implementations of the present disclosure have beendescribed. Nevertheless, it will be understood that variousmodifications may be made without departing from the spirit and scope ofthe present disclosure. Accordingly, other implementations are withinthe scope of the following claims.

What is claimed is:
 1. A computer-implemented method of a relay forcross-chain interactions in a unified blockchain network comprising aplurality of blockchain network instances that are communicativelylinked by two or more relays, wherein each of the plurality ofblockchain network instances comprises an implementation of a blockchainnetwork based on a respective blockchain platform or technology, theeach of the plurality of blockchain network instances has a uniqueblockchain domain name that is recognizable by the two or more relaysand uniquely corresponds to a respective chain identifier of the each ofthe plurality of blockchain network instances in the unified blockchainnetwork, the method comprising: receiving, from a first blockchainnetwork instance and by the relay that is communicatively linked withthe first blockchain network instance and a second blockchain networkinstance in the unified blockchain network, an access request foraccessing the second blockchain network instance, wherein the accessrequest comprises a blockchain domain name of the second blockchainnetwork instance, wherein the blockchain domain name of the secondblockchain network instance is a unique identifier that is recognizableby the two or more relays and uniquely corresponds to a chain identifierof the second blockchain network instance among the plurality ofblockchain network instances in the unified blockchain network, whereinthe chain identifier of the second blockchain network instance indicatesa genesis block of the second blockchain network instance; identifying,by the relay, the chain identifier of the second blockchain networkinstance based on the blockchain domain name of the second blockchainnetwork instance, wherein the chain identifier of the second blockchainnetwork instance indicates a blockchain network configuration of thesecond blockchain network instance; and providing, by the relay, accessto the second blockchain network instance for the first blockchainnetwork instance based on the blockchain network configuration indicatedby the chain identifier of the second blockchain network instance. 2.The method of claim 1, wherein the second blockchain network instance isdesignated by the relay, a local identifier of the second blockchainnetwork instance for use by the relay; and the method further comprisesusing the blockchain domain name of the second blockchain networkinstance as the local identifier of the second blockchain networkinstance or replacing the local identifier of the second blockchainnetwork instance with the blockchain domain name of the secondblockchain network instance.
 3. The method of claim 1, wherein theblockchain domain name of the second blockchain network instance isauthenticated based on a domain certificate of the blockchain domainname of the second blockchain network instance, wherein the domaincertificate of the blockchain domain name of the second blockchainnetwork instance comprises: the blockchain domain name of the secondblockchain network instance, a public key of an owner of the blockchaindomain name of the second blockchain network instance, and a digitalsignature of a certificate authority on the blockchain domain name ofthe second blockchain network instance and the public key of the ownerof the blockchain domain name of the second blockchain network instance.4. The method of claim 1, wherein the chain identifier of the secondblockchain network instance comprises a hash value of the genesis blockof the second blockchain network instance, and a network identifier thatidentifies the second blockchain network instance; and whereinproviding, by the relay, access to the second blockchain networkinstance for the first blockchain network instance based on theblockchain network configuration indicated by the chain identifier ofthe second blockchain network instance comprises: loading the blockchainnetwork configuration indicated by the network identifier thatidentifies the second blockchain network instance corresponding to theblockchain domain name of the second blockchain network instance; usingthe blockchain network configuration to connect to the second blockchainnetwork instance; obtaining a result requested by the first blockchainnetwork instance from the second blockchain network instance; andreturning the result requested by the first blockchain network instanceto the first blockchain network instance.
 5. The method of claim 1,wherein providing, by the relay, access to the second blockchain networkinstance for the first blockchain network instance based on theblockchain network configuration indicated by the chain identifier ofthe second blockchain network instance comprises: providing, by therelay, access to the second blockchain network instance for the firstblockchain network instance via a second relay; wherein the blockchainnetwork configuration indicated by the chain identifier of the secondblockchain network instance is identified by the second relay based onthe same chain identifier of the second blockchain network instance; andwherein the second blockchain network instance is accessed by the secondrelay based on the blockchain network configuration indicated by thechain identifier of the second blockchain network instance.
 6. Themethod of claim 5, wherein the blockchain network configurationindicated by the chain identifier of the second blockchain networkinstance is identified by the second relay according to look-upinformation locally stored at the second relay or from a remote unifiedblockchain domain name server based on the same chain identifier of thesecond blockchain network instance.
 7. The method of claim 1, wherein,after a change or update of the second blockchain network instance, theblockchain domain name of the second blockchain network instance remainsthe same, and the chain identifier of the second blockchain networkinstance is changed to an updated chain identifier while the blockchaindomain name of the second blockchain network instance remains the same,and wherein the updated chain identifier of the second blockchainnetwork instance indicates an updated blockchain network configurationof the second blockchain network instance due to the change or update ofthe second blockchain network instance.
 8. The method of claim 7,further comprising: after the change or update of the second blockchainnetwork instance, receiving, from the first blockchain network instanceand by the relay, a second access request for accessing the secondblockchain network instance, wherein the access request comprising theblockchain domain name of the second blockchain network instance,identifying, by the relay, the updated chain identifier of the secondblockchain network instance based on the blockchain domain name of thesecond blockchain network instance; and providing, by the relay, updatedaccess to the second blockchain network instance for the firstblockchain network instance based on the updated blockchain networkconfiguration indicated by the updated chain identifier of the secondblockchain network instance.
 9. A non-transitory, computer-readablemedium storing one or more instructions executable by a computer systemto perform operations of a relay for cross-chain interactions in aunified blockchain network comprising a plurality of blockchain networkinstances that are communicatively linked by two or more relays, whereineach of the plurality of blockchain network instances comprises animplementation of a blockchain network based on a respective blockchainplatform or technology, the each of the plurality of blockchain networkinstances has a unique blockchain domain name that is recognizable bythe two or more relays and uniquely corresponds to a respective chainidentifier of the each of the plurality of blockchain network instancesin the unified blockchain network, the operations comprising: receiving,from a first blockchain network instance and by the relay that iscommunicatively linked with the first blockchain network instance and asecond blockchain network instance in the unified blockchain network, anaccess request for accessing the second blockchain network instance,wherein the access request comprising a blockchain domain name of thesecond blockchain network instance, wherein the blockchain domain nameof the second blockchain network instance is a unique identifier that isrecognizable by the two or more relays and uniquely corresponds to achain identifier of the second blockchain network instance among theplurality of blockchain network instances in the unified blockchainnetwork, wherein the chain identifier of the second blockchain networkinstance indicates a genesis block of the second blockchain networkinstance; identifying, by the relay, the chain identifier of the secondblockchain network instance based on the blockchain domain name of thesecond blockchain network instance, wherein the chain identifier of thesecond blockchain network instance indicates a blockchain networkconfiguration of the second blockchain network instance; and providing,by the relay, access to the second blockchain network instance for thefirst blockchain network instance based on the blockchain networkconfiguration indicated by the chain identifier of the second blockchainnetwork instance.
 10. The non-transitory, computer-readable medium ofclaim 9, wherein: the second blockchain network instance is designatedby the relay, a local identifier of the second blockchain networkinstance for use by the relay, and the operations further comprise usingthe blockchain domain name of the second blockchain network instance asthe local identifier of the second blockchain network instance orreplacing the local identifier of the second blockchain network instancewith the blockchain domain name of the second blockchain networkinstance.
 11. The non-transitory, computer-readable medium of claim 9,wherein the chain identifier of the second blockchain network instancecomprises a hash value of the genesis block of the second blockchainnetwork instance, and a network identifier that identifies the secondblockchain network instance; and wherein providing, by the relay, accessto the second blockchain network instance for the first blockchainnetwork instance based on the blockchain network configuration indicatedby the chain identifier of the second blockchain network instancecomprises: loading the blockchain network configuration indicated by thenetwork identifier that identifies the second blockchain networkinstance corresponding to the blockchain domain name of the secondblockchain network instance; using the blockchain network configurationto connect to the second blockchain network instance; obtaining a resultrequested by the first blockchain network instance from the secondblockchain network instance; and returning the result requested by thefirst blockchain network instance to the first blockchain networkinstance.
 12. The non-transitory, computer-readable medium of claim 9,wherein, after a change or update of the second blockchain networkinstance, the blockchain domain name of the second blockchain networkinstance remains the same, and the chain identifier of the secondblockchain network instance is changed to an updated chain identifierwhile the blockchain domain name of the second blockchain networkinstance remains the same, and wherein the updated chain identifier ofthe second blockchain network instance indicates an updated blockchainnetwork configuration of the second blockchain network instance due tothe change or update of the second blockchain network instance.
 13. Asystem for cross-chain interactions by a relay in a unified blockchainnetwork comprising a plurality of blockchain network instances that arecommunicatively linked by two or more relays, wherein each of theplurality of blockchain network instances comprises an implementation ofa blockchain network based on a respective blockchain platform ortechnology, the each of the plurality of blockchain network instanceshas a unique blockchain domain name that is recognizable by the two ormore relays and uniquely corresponds to a respective chain identifier ofthe each of the plurality of blockchain network instances in the unifiedblockchain network, the system comprising: one or more computers; andone or more computer-readable memories coupled to the one or morecomputers and having instructions stored thereon which are executable bythe one or more computers to perform operations comprising: receiving,from a first blockchain network instance and by the relay that iscommunicatively linked with the first blockchain network instance and asecond blockchain network instance in the unified blockchain network, anaccess request for accessing the second blockchain network instance,wherein the access request comprises a blockchain domain name of thesecond blockchain network instance, wherein the blockchain domain nameof the second blockchain network instance is a unique identifier that isrecognizable by the two or more relays and uniquely corresponds to achain identifier of the second blockchain network instance among theplurality of blockchain network instances in the unified blockchainnetwork, wherein the chain identifier of the second blockchain networkinstance indicates a genesis block of the second blockchain networkinstance; identifying, by the relay, the chain identifier of the secondblockchain network instance based on the blockchain domain name of thesecond blockchain network instance, wherein the chain identifier of thesecond blockchain network instance indicates a blockchain networkconfiguration of the second blockchain network instance; and providing,by the relay, access to the second blockchain network instance for thefirst blockchain network instance based on the blockchain networkconfiguration indicated by the chain identifier of the second blockchainnetwork instance.
 14. The system of claim 13, wherein: the secondblockchain network instance is designated by the relay, a localidentifier of the second blockchain network instance for use by therelay, and the operations further comprise using the blockchain domainname of the second blockchain network instance as the local identifierof the second blockchain network instance or replacing the localidentifier of the second blockchain network instance with the blockchaindomain name of the second blockchain network instance.
 15. The system ofclaim 13, wherein the blockchain domain name of the second blockchainnetwork instance is authenticated based on a domain certificate of theblockchain domain name of the second blockchain network instance,wherein the domain certificate of the blockchain domain name of thesecond blockchain network instance comprises: the blockchain domain nameof the second blockchain network instance, a public key of an owner ofthe blockchain domain name of the second blockchain network instance,and a digital signature of a certificate authority on the blockchaindomain name of the second blockchain network instance and the public keyof the owner of the blockchain domain name of the second blockchainnetwork instance.
 16. The system of claim 13, wherein the chainidentifier of the second blockchain network instance comprises a hashvalue of the genesis block of the second blockchain network instance,and a network identifier that identifies the second blockchain networkinstance; and wherein providing, by the relay, access to the secondblockchain network instance for the first blockchain network instancebased on the blockchain network configuration indicated by the chainidentifier of the second blockchain network instance comprises: loadingthe blockchain network configuration indicated by network identifierthat identifies the second blockchain network instance corresponding tothe blockchain domain name of the second blockchain network instance;using the blockchain network configuration to connect to the secondblockchain network instance; obtaining a result requested by the firstblockchain network instance from the second blockchain network instance;and returning the result requested by the first blockchain networkinstance to the first blockchain network instance.
 17. The system ofclaim 13, wherein providing, by the relay, access to the secondblockchain network instance for the first blockchain network instancebased on the blockchain network configuration indicated by the chainidentifier of the second blockchain network instance comprises:providing, by the relay, access to the second blockchain networkinstance for the first blockchain network instance via a second relay;wherein the blockchain network configuration indicated by the chainidentifier of the second blockchain network instance is identified bythe second relay based on the same chain identifier of the secondblockchain network instance; and wherein the second blockchain networkinstance is accessed by the second relay based on the blockchain networkconfiguration indicated by the chain identifier of the second blockchainnetwork instance.
 18. The system of claim 17, wherein the blockchainnetwork configuration indicated by the chain identifier of the secondblockchain network instance is identified by the second relay accordingto look-up information locally stored at the second relay or from aremote unified blockchain domain name server based on the same chainidentifier of the second blockchain network instance.
 19. The system ofclaim 13, wherein, after a change or update of the second blockchainnetwork instance, the blockchain domain name of the second blockchainnetwork instance remains the same, and the chain identifier of thesecond blockchain network instance is changed to an updated chainidentifier while the blockchain domain name of the second blockchainnetwork instance remains the same, and wherein the updated chainidentifier of the second blockchain network instance indicates anupdated blockchain network configuration of the second blockchainnetwork instance due to the change or update of the second blockchainnetwork instance.
 20. The system of claim 19, wherein the operationsfurther comprise: after the change or update of the second blockchainnetwork instance, receiving, from the first blockchain network instanceand by the relay, a second access request for accessing the secondblockchain network instance, wherein the access request comprising theblockchain domain name of the second blockchain network instance,identifying, by the relay, the updated chain identifier of the secondblockchain network instance based on the blockchain domain name of thesecond blockchain network instance; and providing, by the relay, updatedaccess to the second blockchain network instance for the firstblockchain network instance based on the updated blockchain networkconfiguration indicated by the updated chain identifier of the secondblockchain network instance.